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METHOD, DEVICE AND SOFTWARE FOR ORDERING 
AND PAYING FOR A PURCHASE 

FIELD OF THE INVENTION 

[0001] The invention relates to ordering and making payment for a purchase, 
and more particularly methods, devices and software for ordering and paying for a 
purchase using a single action. 



BACKGROUND OF THE INVENTION 

[0002] Selecting and paying for goods or services over the Internet may 
involve many steps. A typical sequence at a typical merchant web site on the 
world-wide web may be as follows: 

a) Merchant web site sends HTML pages, that describe the merchant's 
products, to buyer's web browser. 

b) Buyer selects products which are added to a notional "shopping cart". 
Buyer may then navigate to pages describing other products offered for 
sale by the merchant. 

c) Steps a) and b) are repeated until the buyer has chosen all the products he 
wishes to purchase. 

d) Buyer indicates that he wishes to "check out", i.e. to pay for the products 
buyer has chosen and put into his shopping cart. 

e) Merchant web site sends a check-out page to buyer's browser. 

f) Buyer chooses a preferred payment technique (e.g. a credit card). 

g) Merchant web site sends a page to solicit information relating to the 
payment technique (e.g., credit card number, PIN, expiry date, cardholder 
name, billing address). 
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h) Buyer fills in the page of information relating to the selected payment 
technique. 

i) Merchant web site sends a page to solicit confirmation of the payment 
j) Buyer confirms the payment. 

k) Merchant processes the payment. 

I) Merchant arranges delivery of product to buyer. 

[0003] Merchants wish to make it as easy as possible for buyers to purchase 
their products. One aspect of a purchase that can be particularly burdensome is 
payment. Many of the steps in the above time-consuming process relate to 
making payment. Merchants wish to reduce the effort which a buyer must expend 
in order to make a payment, since reducing this effort may lead to increased 
sales. This has led to the development of many techniques for reducing the work 
performed by a buyer to make a payment. 

[0004] For example, one such technique is pre-authorized payment through a 
third party. After establishing an account with the third party, a buyer informs a 
merchant that it should take payment from the account, and directs the third party 
to pay the funds on receiving a request from the merchant. The account is one 
into which the buyer has previously deposited funds, or from which the buyer can 
draw credit. 

[0005] This approach has some drawbacks. For example, it may take 
significant time and effort to set up this type of an account and make such a 
payment. Also, the pre-authorized payment mechanism is not under the buyer's 
control. The merchant may, accidentally or fraudulently, obtain funds from the 
third party which the buyer does not want to pay. The buyer may never discover 
this invalid payment, or may not discover it for a long period of time. Furthermore, 
it is often time consuming and difficult to prevent any future payments of this type 
from taking place. The buyer must communicate with both the merchant and the 
third party to terminate the previously authorized payments. 
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[0006] An approach to minimizing the effort needed to order a product is 
described in U.S. Patent 5,960,411 (Hartman et al.). With this approach, primarily 
intended for use on the Internet, a merchant stores, in a computer database, 
information about how the buyer wishes to pay for purchases. The information 
may include, for example, credit card numbers and expiry dates, billing address, 
the buyer's name, and other information needed for marketing or security 
purposes. This information about the buyer is saved with a client identifier. In 
order to make a payment, the buyer identifies himself by using a keyboard to enter 
the client identifier. The merchant system uses the client identifier to locate the 
payment information and uses the payment information to effect payment. 

[0007] This approach may reduce the effort to make a payment under certain 
circumstances, but also has certain drawbacks. For example, although entering a 
buyer ID and password is not much work compared to entering all the information 
needed to completely specify a payment, it may still be a lot of work to perform, 
especially if the transaction is intended to be very quick. Requiring a buyer to 
enter a user ID and password is a disproportionate amount of work to do, for 
example, when the payment is for a very small amount of money (e.g. 25 cents). 
Also, with this approach, the buyer must be known to the merchant in advance. At 
least once, probably on the first payment the buyer makes to a merchant, the 
buyer must enter detailed personal identification and payment information which 
the merchant then stores in its databases. The merchant needs to manage a lot of 
data about each buyer that wants to make payments in this manner. Furthermore, 
the personal data about each buyer that is stored by a merchant is, in many 
jurisdictions, subject to a privacy regime that gives the buyer rights to see and 
correct the data. Thus, the merchant must provide systems that enable a buyer to 
examine and alter the stored data. Buyers are also concerned about the security 
of the information stored by the merchant, and about the potential impact on their 
privacy should this data not be carefully protected. 

[0008] As will be apparent, a particular drawback to the above mentioned 
approaches is lack of support for making payments anonymously. In each case 
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the merchant must know about the buyer and the buyer's payment information 
before being able to perform a payment. Because payment cannot be made 
anonymously, one buyer may fraudulently pretend to be another buyer. This may 
lead to high fraud rates. 

[0009] Also, systems dependent on buyer identification must also provide 
recourse - the ability for a buyer who has incorrectly been charged by a merchant 
to reverse the payment. Recourse means that even though a merchant believes it 
has been paid for its product, the payment may be cancelled and taken back at 
some indeterminate time in the future. This recourse requirement greatly 
complicates the design and operation of the payment service, and significantly 
increases its operating cost. 

[0010] Micro-payments are small value payments, typically of amounts less 
than $10. If a buyer is making a small payment, then the buyer wants to make a 
correspondingly small effort in order to accomplish the payment. Filling in a form 
that asks for the buyer's name, billing address, credit card number, credit card 
expiry date, and credit card security code is more work than most people are 
willing to perform in order to pay 25 cents. Given their drawbacks, the systems 
above are not well suited for micro-payments because they require a buyer to 
identify himself and/or his account at the time of making a payment. By practicing 
the teachings of the present invention, the effort to make a payment can be largely 
eliminated, to bring the effort in line with the small value of a micro-payment. 

[0011] Clearly then, there is a need for an improved method, device and 
software to simplify order and payment for purchases. 

SUMMARY OF THE INVENTION 

[0012] The present invention provides a method, device and software for 
allowing a buyer to order and pay for products with minimal action required on the 
part of the buyer. 
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[0013] In an embodiment, a display component displays to the buyer a product 
available for purchase from a merchant through a merchant computing device. A 
purchase order component is configured to send to the merchant, in response to a 
single purchasing action taken by the buyer to purchase a product displayed by 
the display component, a purchase order for the product by way of a data 
network. A value storage component under control of the buyer stores data 
representative of a currency of an issuer, verifiable as representing the currency 
by the merchant. The value storage component is configurable to electronically 
transfer data representative of an amount of the currency in response to a request 
from the merchant. 

[0014] In an aspect of the present invention, there is provided a buyer 
computing device operable by a buyer for purchasing a product from a merchant 
by way of a data network, comprising a network interface component for 
exchanging data by way of the data network; a display component for displaying a 
product available for purchase from the merchant through a merchant computing 
device; a purchase order component configured to send to the merchant, in 
response to a single purchasing action taken to purchase a product displayed by 
the display component, a purchase order for the product by way of the data 
network; and a value storage component for electronically storing data 
representative of a currency of an issuer, and verifiable as representing the 
currency by the merchant, the value storage component being configurable to 
electronically transfer data representative of an amount of the currency to the 
merchant in response to the single purchasing action. 

[0015] In another aspect of the invention, there is provided a client-server 
system for purchasing a product available from a merchant by way of a data 
network. The system comprises, on a buyer client computing device, a network 
interface component for exchanging data by way of the data network; a display 
component for displaying a product available for purchase from the merchant 
through a merchant computing device; a purchase order component configured to 
send to the merchant, in response to a single purchasing action taken to purchase 
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a product displayed by the display component, a purchase order for the product 
by way of the data network; a value storage component for electronically storing 
data representative of a currency of an issuer, and verifiable as representing the 
currency by the merchant. The system comprises, on a merchant operated server 
computing device, a network interface component for exchanging data by way of 
the data network; a payment handler component configurable to request from the 
value storage component electronic transfer of data representative of an amount 
of the currency to the merchant in response to the single purchasing action. 

[0016] In another aspect of the invention, there is provided a method of 
purchasing a product from a merchant by way of a data network comprising, on a 
network enabled buyer computing device, providing a display component for 
displaying a product available for purchase from the merchant through a merchant 
computing device; providing a purchase order component for sending to the 
merchant, in response to a single purchasing action taken to purchase a product 
displayed by the display component, a purchase order for the product by way of 
the data network; providing a value storage component for electronically storing 
data representative of a currency of an issuer, and verifiable as representing the 
currency by the merchant, the value storage component being configurable to 
electronically transfer data representative of an amount of the currency to the 
merchant in response to the single purchasing action. 

[0017] In another aspect of the invention, there is provided a computer 
readable medium, storing computer executable software instructions that when 
loaded at a buyer computing device comprising a processor and processor 
readable memory adapt the buyer computing device to provide a display 
component for displaying a product available for purchase from the merchant 
through a merchant computing device; provide a purchase order component for 
sending to the merchant, in response to a single purchasing action taken to 
purchase a product displayed by the display component, a purchase order for the 
product by way of the data network; provide a value storage component to 
electronically store data representative of a currency of an issuer, and verifiable 
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as representing the currency by the merchant, the value storage component being 
configurable to electronically transfer data representative of an amount of the 
currency to the merchant in response to the single purchasing action. 

[0018] Other aspects and features of the present invention will become 
apparent to those of ordinary skill in the art upon review of the following 
description of specific embodiments of the invention in conjunction with the 
accompanying figures. 



BRIEF DESCRIPTION OF THE DRAWINGS 

[0019] In the figures which illustrate by way of example only, embodiments of 
the present invention, 

[0020] FIG. 1 illustrates the major components of an order and payment 
method and system and their interactions during a payment process; 

[0021] FIG. 2A shows a possible presentation of products for sale on an 
Internet site, which may be paid for in a conventional manner; 

[0022] FIG. 2B shows a possible presentation of products for sale on an 
Internet site, in manners exemplary of an embodiment of the present invention; 

[0023] FIG. 3 shows an enhanced version of the method and system of FIG. 1, 
adding an authorization list component; 

[0024] FIG. 4 illustrates an alternative embodiment of the method and system 
illustrated in FIG. 1. 



DETAILED DESCRIPTION 

[0025] FIG. 1 schematically illustrates major software components (value store 

100, display 200, payment handler 300, and merchant site 400), exemplary of 
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embodiments of the present invention, and communication channels between 
them. Value store 100 and display 200 are typically pieces of software that reside 
on and execute their operations within a buyer's personal computer. Payment 
handler 300 and merchant site 400 are typically pieces of software that reside on 
server computers operated by or for a merchant that sells its products over the 
Internet. 

[0026] Specifically, value store 100 and display 200 run on a personal 
computer. This computer may be a desktop personal computer, a notebook 
computer, a hand held digital assistant (e.g. Palm Pilot), a cell phone, or any other 
electronic devices including a credit card sized smart card that is able to deliver 
the necessary functionality. 

[0027] Display 200 is a piece of software separate from, but running on the 
same computer as, value store 100, but this is not necessary. The functionality of 
the display 200 and value store 100 may be combined into a single piece of 
software running on one computer, or split into two or more pieces of software 
running on one or more computers which communicate with each other in order to 
accomplish the buyer side of a payment. 

[0028] Payment handler 300 and merchant site 400 may be on the same 
computer or on two or more computers which communicate with each other in 
order to accomplish the merchant side of a payment. Payment handler 300 and 
merchant site 400 may be integrated to become a single process on one 
computer. 

Network Infrastructure 

[0029] In the illustrative embodiment, the computers hosting software 

components 100, 200, 300, and 400 may be inter-connected by a conventional 

computer network communications infrastructure. For example, the 

communications network infrastructure may be a packet switched data network, 

compliant with standard protocols which make up the Internet and the World-Wide 

Web, including the Internet Protocol (IP), Transport Control Protocol (TCP), 
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Hyper-Text Transfer Protocol (HTTP), and others. 

[0030] Each component 100, 200, 300, 400 may include a network interface 
component which provides this ability to communicate with one or more other 
components 100, 200, 300, 400, as shown in the drawings and described herein. 
For example, the network interface component in each of 100, 200, 300 and 400 
may include TCP/IP protocol stacks, which protocol stacks are often included as 
part of conventional computer operating systems. In the illustrative embodiment, 
the network interface component also includes the ability to communicate via 
software using HTTP. 

Value Store 

[0031] Value store 100 stores data representative of a currency of an issuer 
(herein shortened to "currency data" for brevity). As will become apparent, value 
store 100 is configurable to electronically receive a request for payment and to 
electronically transfer currency data to a merchant. 

[0032] The value store 100 may include, or be in communication with, an 
authorization component. Before value store 100 transfers currency data to a 
merchant, it may use its authorization component to determine whether a 
particular payment should be performed. This authorization component interacts 
with the authorization list 101 as disclosed herein. 

[0033] Those skilled in the art will realize that there are several ways to 
represent currency data. One example of a way to represent currency data is 
described in U.S. patent 5,999,625 (Bellare et al.), where currency data is referred 
to as a "coin" or a "fund representation", and consists of the following fields of 
data: an amount of the currency involved, an expiry date, a random 1024-bit coin 
ID, and a message authentication code computed using a symmetric key 
(randomly chosen by the issuer and kept in secret by the issuer). In an illustrative 
embodiment, a value store 100 uses the network infrastructure to communicate 
with an issuer, requests that the issuer send some currency data to the value 

store 100, and then receives the currency data over the same network 
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infrastructure. 

[0034] Those skilled in the art will realize that there are several ways that value 
store 100 can be implemented, using enhancements to known technologies. By 
way of example, the DigiCash (TM) electronic cash product provides a client 
wallet for performing the functions of storing currency data and responding to 
requests for payment Similarly, a user purse described in U.S. patent 5,999,625 
(Bellare et al.) is also able to store currency data and respond to requests for 
payment. The enhancements may include, for example, using different network 
infrastructure protocols to support communications in another type of network. 
Another enhancement is to support creation of an authorization list 101 for use in 
conjunction with value store 100 (discussed below and illustrated in FIG. 3). 

[0035] Currency data may be verifiable as representing a specific amount of a 
particular currency by the merchant that receives the currency data. Depending on 
the particular way chosen to represent currency data, the merchant may be able 
to examine the data and directly determine its validity, or alternatively the 
merchant may require the assistance of a third party or the issuer of the currency. 
An example of currency data that can be verified by the merchant is the electronic 
money described in U.S. patent 5,453,601 (Rosen). An example of currency data 
that is verified by sending it to the issuer is described in U.S. patent 5,999,625 
(Bellare et al.). 

[0036] Value store 100 typically also provides an appropriate user interface to 
enable a buyer to control its operations including requesting currency data from an 
issuer, sending currency data to a merchant, and managing an authorization list 

Display 

[0037] Display 200 is a component which is able to receive pages of 

information sent over a communications network and then display them to a 

person, such as a buyer. Display 200 also enables a person viewing a page to 

perform actions, like pressing keys on a keyboard or clicking a pointing device, to 

send information back to the sender of the page, such as a web site. 

10 



Attorney Docket: 130-0006US/93393-1 



[0038] In an embodiment, display 200 is a conventional web browser, used to 
view pages of information formatted using hyper-text markup language (HTML) or 
other page description language, and sent over the Internet. The web browser 
interprets HTML commands and displays pages on a display device as they are 
supposed to appear. Two commonly used browsers are Microsoft's Internet 
Explorer and Netscape Navigator. 

[0039] In an embodiment, display 200 runs on the same computer as value 
store 100. The computer on which they run may be a personal computer under 
the control of the buyer. 

Purchase Order Component 

[0040] The buyer of a product should be able to convey to the merchant what 
product(s) the buyer wishes to buy. This information about the product(s) to be 
purchased is referred to as a purchase order. The purchase order information 
typically describes the product to be purchased in normal commercial terms and 
contains any additional information the merchant needs to process the order. This 
information may be as little as just a product identifier, or it may be supplemented 
by description, quantity, or other information useful to the buyer or merchant. 

[0041] In an embodiment of the invention, the purchase order component 
under the control of the buyer conveys the purchase order to the merchant. In 
addition to sending the purchase order, this component also sends to the 
merchant an indication, explicit or implicit, that the buyer wishes to pay for the 
purchase using his value store 100. 

[0042] In an embodiment, the purchase order component is implemented using 

HTML embedded in a page sent to display 200 by merchant site 400. An order & 

pay 402 button (see FIG. 2B and the additional description below), presented by 

HTML coding, sends to merchant site 400 a purchase order which contains a 

product number that identifies the particular product being ordered and also 

indicates that the buyer wishes to pay using the buyer's value store 100. Since 

merchant site 400 originally created the HTML coding being executed by display 
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200, it knows what product the product number identifies. In accordance with the 
teachings of the present invention, the clicking of the order & pay 402 button by 
the buyer also instructs the merchant device that the payment is to be made using 
the buyer's value store 100. 

[0043] It will be apparent to those skilled in the art that there are many other 
ways to build this purchase order component. For example, one of the additional 
embodiments, described below and illustrated with reference to FIG. 4, explains 
that value store 100 itself can initiate communication with payment handler 300. 
That embodiment could be enhanced to enable value store 100 to also contain the 
purchase order component which sends the purchase order to the merchant. 

Merchant 

[0044] A merchant operates components which can send information about 
products that are for sale, accept purchase orders for these products, request 
payment for the products, and accept payment sent to the merchant from the 
buyer in the form of currency data. In an embodiment, the merchant operates two 
major components: a merchant site 400 and a payment handler 300. 

Merchant Site 

[0045] Merchant site 400 sends to a buyer display 200 information about the 
products a merchant has for sale, and enables a buyer to select products the 
buyer wishes to purchase. Merchant site 400 allows a buyer using display 200 to 
indicate how the buyer wishes to make a payment. In accordance with an 
embodiment of the invention, if the buyer chooses to order and make a payment, 
merchant site 400 may send commands and information to other components 
(e.g. to payment handler 300) and wait for a response indicating whether payment 
was successful or not. 

[0046] In an embodiment, merchant site 400 is a web server hosting a web site 
that sends HTML pages to display 200 (e.g. on a buyer's personal computer). In 
an embodiment, the merchant site 400 communicates with payment handler 300 
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by messages which are initiated either by a CGI script, or by a servlet which is 
launched by an HTML message. 

Payment Handler 

[0047] Payment handler 300 is a component that is able to accept commands 
from and respond to merchant site 400. It is also able to send requests to and 
receive currency data from value store 100. It coordinates activities relating to 
payments on the part of the merchant. 

[0048] A software component embodying payment handler 300 may be written 
that performs the following steps (error condition and timeout processing are 
omitted to make the flow more understandable): 

a) Await requests from merchant site 400. 

b) Receive a request from merchant site 400 to obtain payment. This request 
would minimally include the price (e.g. amount and currency) of the 
requested payment, and the location (e.g. network address) of value store 
100 from which to seek payment. In most practical business contexts, the 
payment request will also include invoice information describing the 
products being purchased, and security information which will depend on 
the nature of value store 100 and the network infrastructure being used. 

c) Send a request for payment to value store 100. This request will typically 
include the same information as was in the request received from merchant 
site 400. 

d) Await a response from value store 100. The response includes currency 
data sent by value store 100 for payment, which currency data represents 
an amount of currency sufficient to pay the price of the product purchased. 

e) Examine the received currency data to ensure it is legitimate. Depending 
on the type of value store 100 being used, this may entail sending 
messages to the issuer of the currency stored at value store 100 or other 
systems. Performing of other processing (if any) will be dictated by the 
nature of the value store 100 and its representation of currency data. 
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f) If the currency data is legitimate, then respond to the original request from 
merchant site 400, indicating that payment has been completed. 

Order and Pay With a Single Purchasing Action 

[0049] FIGS. 2A and 2B each show a possible presentation of information 
about products for sale. This list of products could be presented as a page sent by 
merchant site 400 to be displayed by display 200. 

[0050] FIG. 2A shows how a merchant site 400 might present products for sale 
in a conventional manner. Beside each product is a means of selecting the 
product, in the form of a button labeled "choose" 401. This button would provide 
the traditional function on a merchant web site of adding the indicated product to a 
notional shopping cart. This shopping cart is actually a list of items selected by the 
buyer as the buyer moves from place to place in the web site, examining different 
products being offered for sale. The list is usually maintained by the computers at 
the merchant's web site. When the buyer decides to stop selecting products and 
to proceed to pay for them, this list of previously selected items can be presented 
to the buyer and their total value calculated so that the correct amount can be 
paid. 

[0051] In contrast, in exemplary of an embodiment of the present invention, the 
merchant presents an additional or alternative means for selecting each item and 
paying for it at the same time. This means could be visually presented as an 
additional selectable button beside each item, as depicted in FIG. 2B and labeled 
"order & pay" 402. In another embodiment, the choose 401 button could be 
omitted and only the order & pay 402 button may be present. 

[0052] Instead of performing separate actions to add a product to a shopping 
cart, to indicate a desire to check out, to choose a payment mechanism, and then 
to perform the actions needed to fulfill the requirements of the selected payment 
mechanism, choosing a single order & pay 402 action can accomplish all these 
actions at once. 
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[0053] In an embodiment, selecting the order & pay 402 button causes a 
message to be sent to merchant site 400 which in turn causes merchant site 400 
to perform the following: 

a) recognize the product that the buyer wants to purchase; 

b) send a message to payment handler 300 telling it to request payment from 
the buyer's value store 100; 

c) accept payment when it arrives; 

d) arrange delivery of the product to the buyer. 

Examples of Operation 

[0054] Examples of operation of the various components described above, in 
accordance with various illustrative embodiments of the invention, are now 
provided. 

[0055] Referring back to the steps in FIG. 1 (steps correspond to arrow labels 
in FIG. 1), ordering a product and paying for it would proceed as follows: 

a) Merchant site 400 transmits to display 200 information about products 
available for sale. As depicted in FIG. 2B, beside each product is an order & 
pay 402 button. Each such button contains within it information about the 
product that it corresponds to, and information to indicate that the buyer wants 
to pay using his value store 100. 

b) The buyer uses display 200 to examine information about a merchant's 
products. When the buyer has decided which product he wishes to order and 
pay for, the buyer uses display 200 to select the corresponding order & pay 
402 button. This causes display 200 to send a message to merchant site. This 
message identifies the product to be purchased, and that the buyer wishes to 
pay by sending currency data from the buyer's value store 100. 

c) Merchant site 400 starts the payment process by sending a message to 
payment handler 300. The message indicates the amount that must be 
collected from the buyer to pay for the products he has selected, and typically 
provides additional information to enable the buyer to identify the merchant 
and the products chosen. While payment handler 300 is processing the 
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payment, merchant site 400 waits for a response indicating the success or 
failure of the payment. 

d) Payment handler 300 sends a request for payment to the value store 100 
associated with the buyer who is using display 200. This request for payment 
specifies the price that must be paid for the product that was ordered. In a 
typical embodiment, for security reasons, this request for payment additionally 
contains information that identifies the merchant and the product being 
purchased. 

e) In response to the request from payment handler 300, value store 100 sends 
an appropriate amount of currency data to payment handler 300. Typically, 
when a value store 100 sends currency data to a payment handler 300, it 
records which currency data was sent so that the value store 100 will not send 
the same currency data for a subsequent payment transaction. If the value 
store 100 does not hold and cannot obtain sufficient or the right kind of 
currency data, then value store 100 responds to payment handler 300 
indicating that the payment cannot be made; this effectively ends the 
transaction, and payment handler 300 would inform merchant site 400 of this. 

f) If value store 100 sent appropriate currency data to payment handler 300, then 
payment handler 300 informs merchant site 400 that the payment has been 
received. Merchant site 400 then does whatever it needs to do to deliver the 
product to the buyer. This may entail arranging to ship physical goods, or to 
transmit electronic information, or to allow the buyer to play a game, watch a 
movie, or listen to a song being downloaded (streamed) over the Internet. 

[0056] Advantageously, in many cases where the product being sold by the 
merchant is in electronic form, a buyer can select, pay for, and receive the product 
all with a single action. For, example the buyer may easily obtain and pay for 
download data including audio data, video data, image data, text data and 
executable data. This data may be available, for example, on a per access basis, 
or alternatively on a consumption basis based on at least one of time, data 
volume, and bandwidth usage. 
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[0057] Depending on the manner in which the merchant has made the data 
available, the authorization component is configurable to authorize the value store 
100 to transfer sufficient amounts of currency data to pay for download of data 
made available on a per access or consumption basis. In an alternative 
embodiment, the authorization component is configurable to authorize the value 
store 100 to repeatedly transfer sufficient amounts of currency data to pay the 
consumption based charges. 

[0058] With these improvements, the buyer perceives that his effort is being 
spent to choose the product, and the payment part of the process becomes 
largely invisible to the buyer (although it still happens as a consequence of the 
currency data sent by the buyers value store 100 to the merchant's payment 
handler 300). This approach to eliminating virtually all effort required to make 
payments does not depend on the buyer having an account with the merchant or 
establishing any sort of relationship in advance; unlike other payment 
mechanisms, this can be done without the merchant knowing who the buyer is. 

Pre-approve Selected Merchants 

[0059] As described above, a value store 100 receives requests from 
merchants and responds by sending currency data. However, in order to prevent 
the payment handler 300 from withdrawing unapproved amounts, the buyer may 
wish to have an enhanced security feature (such as confirmation of payment). 
While such confirmation could be facilitated by receiving a message on display 
200, and asking the buyer to confirm payment (e.g. by clicking a button) before 
the currency data is sent, this constitutes an extra step. 

[0060] In an alternative embodiment, shown in FIG. 3, value store 100 may 
have an authorization list 101, the contents of this authorization list 101 being 
provided by the buyer. For example, authorization list 101 may include a list of 
merchants that the buyer has approved for payment. Authorization list 101 is 
normally maintained in a persistent storage medium and is under the control of the 
buyer whose money is being managed by value store 100. The buyer can add 
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[0061] A single entry in the list contains information to identify a merchant site 
400 component that may send payment requests, via payment handler 300, to 
value store 100. In an embodiment merchant site 400 may be identified using its 
public key infrastructure (PKI) certificate(s) issued by a well-known certificate 
authority. In an embodiment, the payment request message (step d) in FIG. 3) 
includes the PKI certificate of the merchant site 400. 

[0062] Value store 100 uses the authorization list 101 as follows: If a payment 
request comes from payment handler 300 (step d) in FIG. 3), value store 100 
examines the authorization list 101 (step d2) in FIG. 3) to see if the merchant site 
400 that is requesting payment has been identified by an entry in the authorization 
list 101. If a merchant site 400 is so identified, then value store 100 knows that the 
buyer has approved payments to the identified merchant. Therefore value store 
100 does not need to ask the buyer for approval of the payment. 

[0063] The result of this enhancement of a value store 100 with an 
authorization list 101 is that payment handler 300 can send a request for payment 
to value store 100 which, in turn, can send the payment, all without any further 
confirmation from the buyer. 

[0064] As described above, authorization list 101 may use PKI certificates as a 
way to identify merchant site 400 for future payment requests, saving the 
certificates in the authorization list 101. However, merchant identification could be 
done in many other ways, such as by examining the merchant's name, recognized 
merchant number, network address, URL, or some other identification 
mechanism, or a combination of these. It will be recognized that using an 
encrypted system, such as PKI certificates, is more secure. It is also possible to 
accomplish this function using an identification technology that has not yet been 
invented. In an embodiment in which the value store 100 uses these alternative 
means to identify a merchant site 400, the payment request message (step d) in 
FIG. 3) includes the alternative information being used. 
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[0065] Advantageously, the buyer is in complete control of authorization list 
101, which resides on his own computer or is on another computer under his 
control. This enables the buyer to remove a merchant from the authorization list 
101 whenever desired, thereby immediately and unconditionally stopping pre- 
approved payments to a merchant. 

Additional Embodiments 

[0066] The arrangement of various components and their interactions as 
described above is not intended to limit the invention. Modifications will be 
apparent to those skilled in the art. This section contains a partial list of some of 
the variations that could be implemented. 

[0067] Different possible implementations were identified for value store 100 
and the currency data that it holds. As described, depending on which is 
implemented, payment handler 300 may be able, without assistance from other 
components, to determine the validity of the payment received from value store 
100. Alternatively, payment handler 300 may need to refer to another system, 
perhaps run by an external authority like a bank that issues electronic cash, to 
determine the validity of the payment. This reference to an external authority may 
require extra steps in the order and payment process. 

[0068] Value store 100 may contain electronic representations of money or 
other representations of value. This value may be cash, perhaps designated in 
United States dollars or any other nation's currency. It may be some other 
representation of points, air travel miles, loyalty points, commodities like gold, 
stocks, bonds, or other value that will be accepted as a form of payment by the 
merchant. 

[0069] Another extension from the above description is making the order & pay 

402 button cause a sequence of payments. This might be desired if the total 

amount that needs to be paid cannot be determined in advance. For example, if 

the product being purchased is streaming information (e.g. stock quotes, classical 

music, a movie), then the cost might be $1 per hour of viewing or listening. The 
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order & pay 402 button could cause an initial payment of $1, and cause the 
stream of information to start flowing to the buyer, and the button could 
additionally cause the merchant to request payment of $1 every hour afterwards 
until the buyer stops using the streaming information. 

[0070] Many interactions between components of the system are described as 
a message containing several data elements. Such a single message could be 
implemented as a sequence of messages each containing a subset of the data 
elements. 

[0071] Message interactions between two components of the system, which 
are described as being direct, could be indirect. For example if component A 
directly sends a message to component C, this interaction could be accomplished 
by component A sending a message to component B with an indication, explicit or 
implicit, that part or all of the message should be forwarded to component C. As 
an illustration of this possibility, in FIG. 1, step b) entails the display 200 sending a 
message to the merchant site 400. This message flow could be directed from the 
display 200 to the value store 100 which in turn could forward the message to the 
merchant site 400. 

[0072] In an embodiment, communication between the modules that make up 
the system is done using Internet communications. The communication could, in 
an alternate embodiment, be done using radio, satellite, infra-red, wireless, 
telephonic, or other wired communication media. 

[0073] The product being paid for is not limited to products that can be 
delivered directly over the Internet. The product may, for example, be a ticket (that 
may need to be printed by the buyer) that provides access to a product or service, 
online or not. The product may be one that must be shipped somewhere as 
directed by the buyer. 

[0074] Buyer selection actions are described as clicks on buttons. These clicks 
can be replaced by any of several different types of actions as long as the actions 

suffice to indicate the buyer's intentions. For example, a selection action on any 

20 



Attorney Docket: 130-0006 US/93393-1 



pointer device, a voice command, a key press, a button or toggle or slide may be 
activated on a keyboard or on a wireless device. 

[0075] In an embodiment, authorization list 101 and value store 100 may be 
configured to authorize payment up to a maximum predetermined amount or 
number of purchase transactions. For example, this maximum may be specified 
per merchant site 400, or per purchase transaction. 

[0076] Authorization list 101 and value store 100 could be configured to allow a 
buyer to control the effect of all the list entries as a group, such as: the maximum 
amount of currency data allowed in all transactions that are approved by any entry 
in the whole list; or the maximum number of transactions that should be allowed 
by the whole list. These enhancements provide a buyer with greater control over 
the payment authorization that is enabled by the authorization list 101. 

[0077] Some merchants may operate more than one merchant site 400. The 
authorization list 101 could be altered so that its entries identify merchants, 
instead of or in addition to identifying the sites operated by them, so that a single 
authorization list 101 entry could provide approvals for purchases from more than 
one merchant site 400. 

[0078] A single payment handler 300 could gather payments on behalf of many 
merchant sites 400. In this situation, the authorization list 101 could be altered so 
that its entries identify payment handlers 300 instead of or in addition to merchant 
sites 400. 

[0079] Value store 100 may be segmented into different groupings of value, 
e.g. by currency (e.g. U.S. dollars, Canadian dollars, Euros); or by issuer; or both. 
The buyer may be asked to configure value store 100, explicitly or implicitly, to 
choose the value for a particular payment from one or more of these segments. 
Information may be added to the authorization list 101 to indicate that purchases 
from certain merchants should choose value from a specific segment or group of 
segments. 
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[0080] In an embodiment, the information about the products available for 
purchase and the buyer's selection of products to purchase are done by means of 
display 200 which uses HTML to describe pages of information and interaction 
with the buyer. It is possible to perform these interactions between the merchant 
and the buyer using custom software instead of a standard browser. The 
information sent to the buyer does not need to be represented using any particular 
page presentation mechanism: HTML can be replaced by Adobe's PDF, by XML, 
or any other page description mechanism. 

[0081] In FIG. 1, step c) entails merchant site 400 informing payment handler 
300 that it should start communicating with value store 100. The conversation 
between value store 100 and payment handler 300 could be initiated in many 
different ways. For example, it could be initiated by merchant site 400 or display 
200 telling value store 100 to start a conversation with payment handler 300. FIG. 
4 illustrates one of several possible approaches to this alternative embodiment, 
the steps (identified in FIG. 4) being as follows: 

a) Merchant site 400 transmits to display 200 information about products 
available for sale. 

b) The buyer uses display 200 to indicate that he wishes to order and pay using 
the method described by this invention. 

c) Merchant site 400 sends information about the payment to payment handler 
300, so that payment handler 300 will recognize the order and payment it is 
about to receive. 

d) Merchant site 400 sends information about the payment to display 200 to 
enable it to tell value store 100 to start the payment process. This information 
may, for example, include information about how to contact payment handler 

300. 

e) Display 200 sends payment information details to value store 100. 

f) Value store 1 00 sends currency data to payment handler 300. 

g) Payment handler 300 informs Merchant site 400 that payment has been 
completed. 
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[0082] In FIG. 2B, beside each product there is a choose 401 button and also 
an order & pay 402 button. These could be merged into a single button. Activation 
of this specially programmed button could examine the client computer to 
determine whether it has an appropriate value store 100, and if there is such a 
value store 100, then the button could act like a order & pay 402 button. 
Alternatively, if there is no appropriate value store 1 00 installed on the buyer's 
computer, then the button could act like a choose 401 button, perhaps adding the 
selected product to a notional shopping cart mechanism. 

[0083] The explanation and discussion of exemplary embodiments of the 
invention describes its use to purchase a product from a merchant. It can 
additionally be used for any type of transfer of value from one party to another. 
Examples of other types of payments include: a payment from one individual to 
another; or a payment to a charity which does not deliver a product to the payer. 
The invention describes the interaction of selection of a product, and paying for it; 
but some merchants sell only one product in which case only the payment transfer 
portions of this invention would be used. 

[0084] Of course, the above described embodiments are intended to be 
illustrative only and in no way limiting. The described embodiments of carrying 
out the invention are susceptible to many modifications of form, arrangement of 
parts, details and order of operation. The invention, rather, is intended to 
encompass all such modification within its scope, as defined by the claims, and 
their equivalents. 
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